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The present invention relates to an arrangement for distributing and dispatching traffic in a network, especially H.323 generated traffic, 
which arrangement comprises one or more gatekeepers, here designated as so-called external or real gatekeepers, arid for the purpose of 
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AN ARRANGEMENT FOR DISTRIBUTING AND DESPATCHING TRAFFIC IN 
A NETWORK , ESPECIALLY H.323 GENERATED TRAFFIC 



Field of the invention 

5 

The present invention relates to an arrangement for dis- 
tributing and dispatching traffic in a network, especially 
H.323 generated traffic, which arrangement comprises one or 
more gatekeepers, here designated as so-called external or 
10 real gatekeepers. 



The problem areas 

Today there does not exist any lightweight solution for 
distributing and dispatching H.323 generated traffic. 

15 

Known solutions and problems with these 

It is perfectly possible to distribute and dispatch H.323 
by using a gatekeeper. It might -however be costly to run a 
full fledge gatekeeper for distributing and dispatching 
20 H.323 generated traffic if the intention only is to dis- 
tribute and dispatch H.323 generated traffic. A real gate- 
keeper is complex and has to know about lots of messages 
etc. described in H.323. An endpoint may be any kind of 
H.323 based equipment. 

2 5 In H.323 version 2, redundancy of gatekeepers are de- 
scribed, where one gatekeeper is instructing the endpoint 
to contact another known gatekeeper if itself can not ful- 
fil the service requested. It requires however that end- 
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points understand version 2 of the protocol, and interpret 
the message fields. This solution is not applicable for 
load balancing, as it has no mechanism for one real gate- 
keeper to know of the other, or any mechanism to report 
5 load between them. 

Objects of the invention 

An object of the present invention is to provide an ar- 
10 rangement by which the distribution and dispatch of H.323 
generated traffic can be provided in a far more expedient 
and less costly manner. 

Another object of the present invention is to provide an 
15 arrangement by which endpoints can be put in contact with 

so-called external or real gatekeepers without having to be 
reconfigured depending on which gatekeeper they want to 
communicate with. 

2 0 A further object of the present invention is to provide an 
arrangement by which supplementary achievements, comprising 
for example load balancing, QoS (Quality of Service) , in- 
formation about cost, etc. can easily be implemented. 

25 Still another object of the present invention is to provide 
an arrangement by which the messages associated with so- 
called external or real gatekeepers are utilised in a ra- 
tional and effective manner. 
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Brief disclosure of the invention 



The above objects are achieved in an arrangement as stated 
in the preamble, which according to the present invention 
5 is characterized by the introduction of one or more inter- 
nal and lightweight gatekeepers, where internal means that 
they are arranged in a certain domain, and they are light- 
weight in the sense that each gatekeeper support a limited 
range of the H.323 message set, each such lightweight gate- 
10 keeper basically understanding any message used by any end- 
point when registering to a real gatekeeper and that each 
lightweight gatekeeper is adapted to put an endpoint of its 
domain in contact with an external or real gatekeeper, out- 
side said domain. 

15 

In other words, the present invention performs the H.323 
distribution and dispatch by utilising an extreme light- 
weight gatekeeper that basically understands the GRQ (Gate- 
keeper Request) , GCF (Gatekeeper Confirm) and GRJ (Gate- 

2 0 keeper Reject) H.323 RAS messages. 

These messages are stated in H.225 and are used by end- 
points when registering to a gatekeeper. Such a lightweight 
gatekeeper is able to put an endpoint within the light- 
25 weight gatekeeper's domain in contact with a full fledge or 
real gatekeeper outside its own domain. 

How to achieve supplementary achievements as e.g. load bal- 
ancing is also described in the text below. Some of the 

3 0 ways described here not only involves GRQ, GCF and GRJ. 
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Further features and advantages of the present invention 
will appear from the following description taken in con- 
junction with the enclosed drawings. 

5 Brief description of the drawings 

Figure 1 is a sketch of a typical scenario in which the 
distributed gatekeeper system might be utilised with end- 
points, internal (lightweight) gatekeeper located inside 
10 the domain or LAN and external (real) Gatekeepers located 
outside. The network components as e.g. routers etc. are 
not outlined. 

Figure 2 is a network scenario in which the distributed 
15 gatekeeper system may be applied. Not all of the components 
within the ISP domain are outlined, neither is network- 
related equipment as e.g. routers etc. outlined. An example 
of a LAN domain is sketched in Figure 1. The internal gate- 
keepers may be connected in any way and any number towards 
20 the external gatekeepers. An arbitrary number of external 
gatekeepers may be connected. 

Figure 3 shows the message exchange during start up of a 
real gatekeeper, when the real gatekeeper register a light - 
2 5 weight gatekeeper. 

Figure 4 shows the message transfer in communication be- 
tween real and lightweight gatekeeper, as the lightweight 
gatekeeper collects information relating to e.g. the load 
30 situation of the real gatekeeper. 

Figure 5 gives a system overview. 
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Detailed description of embodiments 

An endpoint that wants to initiate a session towards an- 
5 other endpoint has first to register to a gatekeeper. An 
endpoint performs this by sending a GRQ (see Figure 1 GRQ X ) 
to the lightweight gatekeeper. The lightweight gatekeeper 
only understands and responds to GRQs . As the lightweight 
gatekeeper also has knowledge of real gatekeepers outside 

10 its own domain, it responds to the endpoint with a GCF (see 
Figure 1 GRQ 4 ) with the gatekeeper id of an appropriate 
full fledge gatekeeper outside its own domain. In advance 
the lightweight gatekeeper must have gained knowledge of 
valid gatekeepers outside its domain (information like IP 

15 address) . The method for gaining and updating the knowledge 
of external gatekeepers is described in the text below, in 
connection with the discussion of Figure 4. In addition, 
each time an endpoint connects to the lightweight gate- 
keeper, the lightweight gatekeeper should use the same sig- 

2 0 nals, i.e. GRQ (see Figure 1 GRQ 2 ) and GCF (see Figure 1 
GRQ 3 ) , towards the real gatekeepers e.g. to check which 
gatekeepers that allow the endpoint to be connected. 

Figure 1 only indicates one possible scenario on how the 

2 5 lightweight gatekeeper communicates with the real gatekeep- 

ers. Alternatively the internal gatekeeper may directly 
provide the address of an external gatekeeper in the GCF 
towards the endpoint as a response to the GRQ. Figure 2 in- 
dicates how the arrangement is deployed when taking ISPs, 

3 0 LAN and Internet into account. 
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Load balancing may be obtained through the inventive 
method. The lightweight gatekeeper has knowledge of valid 
real gatekeepers' load and, on this basis, the lightweight 
gatekeeper might distribute the traffic towards the least 
5 loaded gatekeeper . 

Each real gatekeeper should be configured to know a light- 
weight gatekeeper, and should register with this during 
start-up. This can be done using Registration Request 
(RRQ) . The lightweight gatekeeper replies with Registration 
10 Confirm (RCF) including an endpoint identifier, which the 
real gatekeepers may use in future communication with the 
lightweight gatekeeper, and adds the real gatekeeper to its 
internal list of gatekeepers. See Figure 3. 

The ResourceAvailablitylndication (RAI) and ResourceAvail- 
abilityConf irm (RAC) messages (RAS protocol, [1]), are de- 
scribed for use between gateways and gatekeepers. The gate- 
way sends the indication, either periodically, or when the 
resource situation has changed, to the gatekeeper, which 
uses this information when picking the gateway a given call 
is routed to. 

This invention utilizes this mechanism between a real gate- 
keeper and the extended lightweight gatekeeper, in order 
for the lightweight gatekeeper to make more intelligent 
choices when forwarding the GRQ message to the gatekeeper 
25 that will actually be used for registration and call rout- 
ing. 

A real gatekeeper sends RAI with the endpoint identifier 
received during registration and its resource situation 
(see figure 4) . The list of gatekeepers in the lightweight 
3 0 gatekeeper will now be updated with resource information so 
that the gatekeeper dispatcher will not forward a GRQ to a 
gatekeeper which has indicated that it is almost out of re- 
sources. 



15 



20 
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As an alternative to using RAI/RAC, the proprietary non- 
StandardData field of GCF and GRJ might be used for ex- 
changing e.g. QoS information between the lightweight gate- 
keeper and the real gatekeepers. If the lightweight gate- 
5 keeper keeps track of each real gatekeeper's e.g. QoS, e.g. 
in a table form, these tables may be updated each time the 
lightweight gatekeeper receives a GCF or GRJ from a real 
gatekeeper. The lightweight gatekeeper will then read the 
nonStandardData field of these messages and update its ta- 
10 bles. In the same way the clients may indicate their will- 
ingness to pay and hence achieve corresponding e.g. QoS by 
using the nonStandardData field of the GRQ message. 

A simple example of how to utilise the nonStandardData. 
15 field: E.g. load information might be exchanged between a 
real gatekeeper and the lightweight gatekeeper by stating 
that the first byte of the nonStandardData field in the GCF 
message shall contain an integer indicating the gate- 
keeper's load. The same idea applies for exchanging other 

2 0 kind of data. 

Other ways of exchanging information not involving the non- 
StandardData field of GCF, GRJ and GRQ are described below. 

The lightweight gatekeeper should also be able to handle 
25 registration requests (RRQ) from endpoints, but should al- 
ways reject them (RRJ) with reason discovery required, to 
enforce endpoints with manual discovery (configured gate- 
keeper address) to send GRQ. 

As this solution is done transparent to the endpoint, it is 

3 0 not required to support version 2 of H.323, or to interpret 

all the parameters in the messages. 
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The situation between endpoints, lightweight gatekeeper and 
real gatekeepers are shown in Figure 5. As the lightweight 
gatekeeper holds very little cached information (the regis- 
trations) there is no need for redundancy for this entity, 
5 and it may restart automatically after an unexpected crash. 
By using a u time to live" parameter in the real- 
lightweight registrations, the real gatekeepers will auto- 
matically re- register at a given interval, and the system 
is up again. No calls are lost during this period. 

10 Transfer of registered endpoints from one gatekeeper to an- 
other, e.g. during shutdown of one gatekeeper for software 
upgrade, may be done by first unregistering the gatekeeper 
from the lightweight gatekeeper, and then unregister all 
registered endpoints. Normally, an endpoint then tries to 

15 re-register. This attempt should be rejected with reason 
discovery required, thereby forcing the endpoint to send 
GRQ to the lightweight gatekeeper. In this way, gatekeeper 
redundancy is also achieved for version 1 endpoints, which 
can not understand the required version 2 fields for gate- 

20 keeper redundancy. 

Network resource management will be simplified since one 
node (the lightweight gatekeeper) now knows the resource 
situation of all the gatekeepers * belonging" to it. 

25 QoS might also be obtained through the approach according 
to the present invention. If the lightweight gatekeeper is 
able to and has obtained knowledge of which level of QoS 
the different gatekeeper providers are able to provide, 
this information might be utilised for connecting the end- 

3 0 points to the gatekeeper with the QoS level in mind. An 

endpoint might not always want to connect to the gatekeeper 
providing the best QoS because higher QoS might mean higher 
charge . 
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Information of the (current) cost of using the different 
full fledge gatekeepers might also be provided by the same 
approach as described for load balancing and QoS . 

5 Information flow between the lightweight gatekeeper and the 
real gatekeepers 



Several alternatives exist regarding how often the light- 
weight gatekeeper ought to communicate with the external 
10 gatekeepers and hence update the internal tables: 

1) The lightweight gatekeeper may update its internal ta- 
bles statically, i.e. by management. An example of a 
static configuration setting may be that between 0800 

15 and 1000 a certain external gatekeeper doesn't want to 

handle GRQs coming from the lightweight gatekeeper. 

2) The lightweight gatekeeper may update its internal ta- 
bles partly dynamically, i.e. e.g. on GCF, GRJ and RAI 

20 received from the real gatekeepers. 

3) Other H.225 or H.245 messages might be utilised for such 
information exchange, e.g. the H.225' s IRQ (Inf oRequest) 
and IRR (Inf oResponse) 

25 

4) Other ways of exchanging such information also exist. 
Examples may be to use other protocols like TCP, UDP or 
such as Java/RMI, CORBA etc. 

3 0 Any combination of the above mentioned approaches may be 

applied. Besides, information on a client's willingness to 
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pay might be forwarded in the GRQ message, see next chap- 
ter . 

Information flow between endpoints and the lightweight 
5 gatekeeper 

Information that might flow from endpoints to the light- 
weight gatekeeper is e.g. willingness to pay information. 
Hence the lightweight gatekeeper, dependent of the fre- 
10 quency, has valid knowledge of the endpoints, e.g. willing 
ness to pay. 

The way in which this information might be exchanged is ac 
cording to those mechanism described in previous chapter. 

15 

Which real gatekeeper to put an endpoint in touch with 

Another issue is which real gatekeeper the lightweight 
gatekeeper should put an endpoint in contact with. Alterna 
20 tives may be: 

1) Forward the GRQ to a randomly picked real gatekeeper 

2) Forward the GRQ based on internal information. Examples 
2 5 of internal information might be QoS, load, cost, time 

of day etc. 

3) Forward the GRQ to a specific real gatekeeper on the ba 
sis of other criterias 

30 

4) By forward is meant explicitly, i.e. plain forward of 
the GRQ to an external gatekeeper, or implicitly, i.e. 
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the address of the external gatekeeper is directly pro- 
vided in the internal gatekeeper 1 s GCF towards the end- 
point 

5 Advantages 

Such an extremely lightweight gatekeeper is trivial to im- 
plement and only needs small amount of memory and CPU 
power. Due to these modestly demanding requirements it does 

0 not have to execute on dedicated hardware (PCs, worksta- 
tions etc.) An advantage that is a consequence of the 
lightweight approach, is that e.g. a small company that 
thinks it is too costly to put up an own local gatekeeper 
might initiate contracts with one or several gatekeeper 

5 providers . 

Such a distributed approach is trivial to maintain due to 
the fact that all the endpoints only needs to know about 
one gatekeeper, i.e. the lightweight gatekeeper. If the 
0 endpoints communicate directly with the real gatekeepers, 
the endpoints have to be reconfigured depending on which 
gatekeepers they want to communicate with. 

This invention has the great advantage that it allows a 
system of multiple gatekeepers to distribute load evenly, 
5 thereby reducing call setup time and improving the total 
possible utilization compared to the statical endpoint- 
gatekeeper relationship . 



Further the gatekeepers are able to recover automatically 
after a crash, without any external intervention. 



WO 00/48368 PCT/NO00/00030 

12 

Another advantage of the invention is the possibility of 
transferring registered endpoints from one gatekeeper to 
another . 

5 References 

[1] w Call Signaling Protocols and Media Stream Pack- 

etization for Packet Based Multimedia Communications 
Systems" , DRAFT ITU-T Recommendation H. 225.0, 
10 Version 2 
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Patent 



claims 



1. An arrangement for distributing and dispatching traffic 
in a network, especially H.323 generated traffic, which ar- 

5 rangement comprises one or more gatekeepers, here desig- 
nated as so-called external or real gatekeepers, 
characterized by the introduction of one or 
more internal and lightweight gatekeepers, where internal 
means that they are arranged in a certain domain, and they 

10 are lightweight in the sense that each gatekeeper support a 
limited range of the H.323 message set, each such light- 
weight gatekeeper basically understanding any message used 
by any endpoint when registering to a real gatekeeper and 
that each lightweight gatekeeper is adapted to put an end- 

15 point of its domain in contact with an external or real 
gatekeeper, outside said domain. 

2. Arrangement as claimed in claim 1, 

characterized in that each lightweight 
2 0 gatekeeper is adapted to basically understand a subset of 
the messages as stated in H.225, i.e. comprising for exam- 
ple GRQ (Gatekeeper Request) , GCF (Gatekeeper Confirm) , GRJ 
(Gatekeeper Reject) , IRR (Information Request Response) , 
IRQ (Information Request) , RAI (Resource Availability Indi- 
25 cation) , RAC (Resource Availability Confirm) , RRQ (Regis- 
tration Request) , RCF (Registration Confirm) , RRJ (Regis- 
tration Reject) . 

3. Arrangement as claimed in claim 2, 

30 characterized in that each real gatekeeper 
is arranged to register a lightweight gatekeeper during 
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start-up, and each lightweight gatekeeper is arranged to 
maintain a list or table of valid real gatekeepers. 

4 . Arrangement as claimed in claim 3 , 

5 characterized in that said table is sup- 
plemented with resource information indicating the load on 
each particular real gatekeeper. 

5 . Arrangement as claimed in claim 4 , 

10 characterized in that said table is sup- 
plemented with information relating to quality of service 
and cost . 

6. Arrangement as claimed in claim 5, 

15 characterized in that the proprietary non- 
StandardData field of GCF and GRJ messages are used for ex- 
changing information between a lightweight gatekeeper and 
any external real gatekeeper, which field is used to convey 
information used in said supplementary fields of said ta- 

20 ble. 

7. Arrangement as claimed in claim 6, 

characterized in that the proprietary non- 
StandardData field of the GRQ message is used by the client 
25 to communicate for example the desired cost level, type of 
QoS, etc., to the real gatekeeper in question. 

8. Arrangement as claimed in any claim 6 or 7, 
characterized in that for example the 

3 0 first byte of the nonStandardData field in the GCF message 
may contain an integer indicating the load of the real 
gatekeeper. 
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9. Arrangement as claimed in any of the claims 4-8, 
characterized in that lightweight gate- 
keeper may update its internal table or tables statically, 
5 i.e. by management, an example of static configuration set- 
ting being that between 0800 and 10 00 a certain external 
gatekeeper may exclude handling GRQs coming from any light- 
weight gatekeeper. 

10 10. Arrangement as claimed in any of the claims 4-8, 

characterized in that each lightweight 
gatekeeper is adapted to update its internal table or ta- 
bles partly dynamically, e.g. on GCF, GRJ and RAI received 
from any real gatekeeper. 

15 

11. Arrangement as claimed in any of the claims 4-8, 
characterized in that means for exchanging 
such information comprises protocols like TCP, UDP, or such 
as Java/RMI , Corba , etc . 

20 

12. Arrangement as claimed in any of the preceding claims, 
characterized in that any lightweight 
gatekeeper is adapted so as to put an endpoint in contact 
with a real gatekeeper according to the following alterna- 

25 tives: 



1) Forward the GRQ to a randomly picked real gatekeeper 

2) Forward the GRQ based on internal information, exam- 
3 0 pies of such internal information being QoS, load, 

cost, time of day, etc. 
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3) Forward the GRQ to a specific real gatekeeper to a ba- 
sis of other criterias 



4) By forward is meant explicitly, i.e. plain forward of 
5 the GRQ to an external gatekeeper, or implicitly, i.e. 

the address of the external gatekeeper is directly 
provided in the internal gatekeeper's GCF towards the 
endpoint 



10 13. Arrangement as claimed in any of the preceding claims, 
characterized in that one internal light- 
weight gatekeeper is adapted to communicate with a plural- 
ity of endpoints, said plurality of endpoints only knowing 
about said one internal gatekeeper and thereby avoiding re- 

15 configuration. 
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